<div>
  Specify a custom local repository path.
  Shell-like environment variable expansions work with this field, by using the ${VARIABLE} syntax.
  
  Normally, Jenkins uses the local Maven repository as determined by Maven, by default <code>~/.m2/repository</code> and can be overridden by
  &lt;localRepository> in <code>~/.m2/settings.xml</code> (see <a href="https://maven.apache.org/guides/mini/guide-configuring-maven.html#Configuring_your_Local_Repository">Configuring your Local Repository</a>))

  <p>
  This normally means that all the jobs that are executed on the same node shares a single Maven repository.
  The upside of this is that you can save the disk space, the downside is that the repository is not multi process safe and having multiple builds run concurrently can corrupt it.
  Additionally builds could interfere with each other by sharing incorrect or partially built artifacts. For example, you might end up having builds incorrectly succeed,
  just because your have all the dependencies in your local repository, despite that fact that none of the
  repositories in POM might have them.

  <p>
  By using this option, Jenkins will tell Maven to use a custom path for the build as the local Maven repository by using <code>-Dmaven.repo.local</code>
  <br>

  If specified as a relative path then this value well be resolved against the workspace root and not the current working directory.
  <br>
  ie. if <code>.repository</code> is specified then <code>$WORKSPACE/.repository</code> will be used.

  <p>
  This means each job could get its own isolated Maven repository just for itself. It fixes the above problems,
  at the expense of additional disk space consumption.

  <p>
  When using this option, consider setting up a Maven artifact manager so that you don't have to hit
  remote Maven repositories too often.
</div>
